General SIP Parameters

The general SIP parameters are described in the table below.

General SIP Parameters

Parameter

Description

'Classify By Proxy Set Mode'

configure voip > sip-definition settings > classify-by-proxy-set-mode

[ClassifyByProxySetMode]

Defines which IP address to use for classifying the incoming SIP dialog message to a Server-type IP Group, based on Proxy Set.

[0] IP address = (Default) The device checks if the source IP address (ISO Layer 3) of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. If a match is found in the Proxy Set, the call is classified to the IP Group.
[1] Contact Header = The device checks if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. This is only applicable if the header contains a SIP URI that has an IP address (not hostname) in the host part. If a match is found in the Proxy Set, the call is classified to the IP Group. This option is useful, for example, when the source IP address is an internal address.
[2] Both = The device first checks if the source IP address (ISO Layer 3) of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. Only if there is no match, does the device check if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set.

Note:

To enable classification by Proxy Set, configure the IP Group table's 'Classify By Proxy Set' parameter to Enable (see Configuring IP Groups).
Classification using the SIP Contact header is supported only when the header's SIP URI has an IP address (not a DNS hostname).
For IDS, only the source IP address is used (see Configuring IDS Policies).
For TLS Contexts, only the source IP address is used. (If a Proxy Set is not found, the TLS Context configured for the SIP Interface is used.)
This parameter is applicable only to the SBC application.

configure voip > sip-definition settings > max-sdp-sess-ver-id

[MaxSDPSessionVersionId]

Defines the maximum number of characters allowed in the SDP body's "o=" (originator and session identifier) field for the session ID and session version values.

Below is an example of an "o=" line with session ID and session version values (in bold):

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

The valid value range is 1,000 to 214,748,3647 (default).

configure voip > sip-definition settings > unreg-on-startup

[UnregisterOnStartup]

Enables the device to unregister all user Accounts that were registered with the device, upon a device restart. During device start-up, each Account sends a REGISTER message (containing "Contact: *") to unregister all contact URIs belonging to its Address-of-Record (AOR), and then a second after they are unregistered, the device re-registers the Account.

[0] = (Default) Disable
[1] = Enable

To configure Accounts, see Configuring Registration Accounts.

'Send Reject (503) upon Overload'

configure voip > sip-definition settings > reject-on-ovrld

[SendRejectOnOverload]

Disables the sending of SIP 503 (Service Unavailable) responses upon receipt of new SIP dialog-initiating requests when the device's CPU is overloaded and thus, unable to accept and process new SIP messages.

[0] Disable = No SIP 503 response is sent when CPU overloaded.
[1] Enable  = (Default) SIP 503 response is sent when CPU overloaded.

Note: Even if the parameter is disabled (i.e., 503 is not sent), the device still discards the new SIP dialog-initiating requests when the CPU is overloaded.

'SIP 408 Response upon non-INVITE'

configure voip > sip-definition settings > enbl-non-inv-408

[EnableNonInvite408Reply]

Enables the device to send SIP 408 responses (Request Timeout) upon receipt of non-INVITE transactions. Disabling this response complies with RFC 4320/4321. By default, and in certain circumstances such as a timeout expiry, the device sends a SIP 408 Request Timeout in response to non-INVITE requests (e.g., REGISTER).

[0] Disable = SIP 408 response is not sent upon receipt of non-INVITE messages (to comply with RFC 4320).
[1] Enable = (Default) SIP 408 response is sent upon receipt of non-INVITE messages, if necessary.

'Remote Management by SIP NOTIFY'

configure voip > sip-definition settings > sip-remote-reset

[EnableSIPRemoteReset]

Enables a specific device action upon the receipt of a SIP NOTIFY request, where the action depends on the value in the Event header.

[0] Disable (default)
[1] Enable

The action depends on the Event header value:

"Event: check-sync;reboot=false": Triggers the regular Automatic Update feature (if Automatic Update has been enabled on the device).
"Event: check-sync;reboot=true": Triggers a device restart.
"Event: soft-sync": Triggers the device to disconnect all current calls.
If the 'reboot=' parameter is not specified in the Event header, it defaults to 'true' (i.e., triggers a device restart).

Note: The Event header value is proprietary to AudioCodes.

'Max SIP Message Length'

[MaxSIPMessageLength]

Defines the maximum size (in Kbytes) for each SIP message that can be sent over the network. The device rejects messages exceeding this user-defined size.

The valid value range is 1 to 100. The default is 100.

[SIPForceRport]

Determines whether the device sends SIP responses to the UDP port from where SIP requests are received even if the 'rport' parameter is not present in the SIP Via header.

[0] = (Default) Disabled. The device sends the SIP response to the UDP port defined in the Via header. If the Via header contains the 'rport' parameter, the response is sent to the UDP port from where the SIP request is received.
[1] = Enabled. SIP responses are sent to the UDP port from where SIP requests are received even if the 'rport' parameter is not present in the Via header.

'Reject Cancel after Connect'

configure voip > sip-definition settings > rej-cancel-after-conn

[RejectCancelAfterConnect]

Enables or disables the device to accept or reject SIP CANCEL requests received after the receipt of a 200 OK in response to an INVITE (i.e., call established). According to the SIP standard, a CANCEL can be sent only during the INVITE transaction (before 200 OK), and once a 200 OK response is received the call can be rejected only by a BYE request.

[0] Disable = (Default) Accepts a CANCEL request received during the INVITE transaction by sending a 200 OK response and terminates the call session.
[1] Enable = Rejects a CANCEL request received during the INVITE transaction by sending a SIP 481 (Call/Transaction Does Not Exist) response and maintains the call session.

configure voip > sip-definition settings > call-info-list

[CallInfoListMode]

Defines how the device handles SIP Call-Info headers with multiple values in outgoing SIP messages.

[0] = The device sends the outgoing SIP message with a Call-Info header for each value.
[1] = The device sends the outgoing SIP message with a single Call-Info header that contains all the values (comma-separated list) per RFC 3261.

configure voip > sip-definition settings > verify-rcvd-requri

[VerifyRecievedRequestUri]

Enables the device to reject SIP requests (e.g., ACK, BYE, or re-INVITE) whose user part in the Request-URI is different from the user part in the Contact header of the last sent SIP request.

[0] = (Default) Disable. Even if the user part is different, the device accepts the SIP request.
[1] = Enable. If the user part in the Contact header of the previous SIP request is different to the user part in the Request-URI for in-dialog requests, the device rejects the SIP request. A BYE request is responded with a SIP 481, a re-INVITE request is responded with a SIP 404, and an ACK request is ignored.
[2] = If the user part in the Contact header of the previous SIP request is different to the user part in the Request-URI for dialog-initiating INVITE requests, the device rejects the SIP request.
Verify dialog-initiating INVITE for all required conditions (Via, Source IP and user in Request-URI)
[3] = Verify dialog-initiating INVITE and in-dialog requests.

The [VerifyRecievedRequestUri] parameter functions together with the [RegistrarProxySetID] parameter, as follows:

Handling Dialog-Initiating INVITEs: If the [VerifyRecievedRequestUri] parameter is configured to [2] or [3] and the [RegistrarProxySetID] parameter is configured to some Proxy Set, the device accepts dialog-initiating INVITE requests received from the registrar at which the Accounts (configured in the Accounts table) are registered. For dialog-initiating INVITE requests received from the registrar on a specific SIP Interface, the following rules apply (listed according to priority):
The top-most Via header must contain a host-resolved IP address of the registrar; otherwise, the device drops the INVITE request.
The source IP address must be the same as the IP address of the registrar; otherwise, the device rejects the requests and sends a SIP 403 (Forbidden) response to the registrar.
The user part, specified in the Request-URI header, must be identical to the Contact user part configured for the associated Account, and the Account must be registered. Otherwise, the device rejects the request with a SIP 404 (Not Found) response. If the [RegistrarProxySetID] parameter is not configured or no Accounts are configured, the device accepts the dialog-initiating INVITE request.

Note: This handling is applicable only to the SBC application.

Handling In-dialog Requests: If the [VerifyRecievedRequestUri] parameter is configured to [1] or [3], for all incoming in-dialog requests (including ACK and CANCEL), the device checks if the Request-URI user part matches the remote Contact user part (i.e., the Contact user configured for the Account). If there is no match, the device rejects the request and sends a SIP 481 response for requests such as BYE and CANCEL, or a SIP 404 for other requests, and for ACK it doesn't send any response.

Note: This handling is applicable to the Gateway and SBC applications.

[RegistrarProxySetID]

Defines a Proxy Set for the registrar. The parameter functions together with the [VerifyRecievedRequestUri] parameter. For more information, see the description of the [VerifyRecievedRequestUri] parameter.

The default value is -1 (not defined).

Note: This setting assumes that the SIP Interface has only one registrar.

'Max Number of Active Calls'

configure voip > sip-definition settings > max-nb-of--act-calls

[MaxActiveCalls]

Defines the maximum number of simultaneous active calls supported by the device. If the maximum number of calls is reached, new calls are not established.

The valid range is 1 to the maximum number of supported channels. The default value is the maximum available channels (i.e., no restriction on the maximum number of calls).

'QoS Statistics in Release Msg'

configure voip > sip-definition settings > qos-statistics-in-release-msg

[QoSStatistics]

Enables the device to include call Quality of Service (QoS) statistics in SIP BYE messages and SIP 200 OK responses to BYE messages, using the proprietary SIP header X-RTP-Stat.

[0] Disable (default)
[1] Enable

The X-RTP-Stat header contains the following statistics:

Number of received and sent voice packets
Number of received and sent voice octets
Received packet loss, jitter (in ms), and latency (in ms)

The X-RTP-Stat header contains the following fields:

PS=<voice packets sent>
OS=<voice octets sent>
PR=<voice packets received>
OR=<voice octets received>
PL=<receive packet loss>
JI=<jitter in ms>
LA=<latency in ms>

Below is an example of the X-RTP-Stat header in a SIP BYE message:

BYE sip:302@10.33.4.125 SIP/2.0

Via: SIP/2.0/UDP 10.33.4.126;branch=z9hG4bKac2127550866

Max-Forwards: 70

From: <sip:401@10.33.4.126;user=phone>;tag=1c2113553324

To: <sip:302@company.com>;tag=1c991751121

Call-ID: 991750671245200001912@10.33.4.125

CSeq: 1 BYE

X-RTP-Stat: PS=207;OS=49680;;PR=314;OR=50240;PL=0;JI=600;LA=40;

Supported: em,timer,replaces,path,resource-priority

Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE

User-Agent: Sip-Gateway-/7.40A.600.203

Reason: Q.850 ;cause=16 ;text="local"

Content-Length: 0

Note: The parameter is applicable only to the Gateway application.

'PRACK Mode'

prack-mode

[PrackMode]

Determines the PRACK (Provisional Acknowledgment) mechanism mode for SIP 1xx reliable responses.

[0] Disable
[1] Supported (default)
[2] Required

Note:

The Supported and Required headers contain the '100rel' tag.
The device sends PRACK messages if 180/183 responses are received with '100rel' in the Supported or Required headers.
The parameter is applicable only to the Gateway application.

'Enable Early Media'

early-media

[EnableEarlyMedia]

Global parameter enabling the Early Media feature for sending media (e.g., ringing) before the call is established.

You can also configure this feature per specific calls, using IP Profiles ('Early Media' parameter) or Tel Profiles ('Enable Early Media' parameter). For a detailed description of the parameter and for configuring the feature, see Configuring IP Profiles or Configuring Tel Profiles.

Note: If the feature is configured for a specific profile, the settings of the global parameter is ignored for calls associated with the profile.

'Enable Early 183'

early-183

[EnableEarly183]

Global parameter that enables the device to send SIP 183 responses with SDP to the IP upon receipt of INVITE messages. You can also configure this feature per specific calls, using IP Profiles ('Early 183' parameter). For a detailed description of the parameter and for configuring this feature in the IP Profiles table, see Configuring IP Profiles.

Note: If you configure this feature for a specific IP Profile, the device ignores this global parameter for calls associated with the IP Profile.

[IgnoreAlertAfterEarlyMedia]

Defines the device's interworking of Alerting messages for IP-to-Tel calls (ISDN). It determines whether the device sends a 180 Ringing response to the caller after the device sends a 183 Session Progress response to the caller. The 180 Ringing response indicates that the INVITE has been received by the ISDN side and that alerting is taking place (i.e., ISDN Progress message), indicating to the IP PBX to play a ringback tone. The 183 Session Progress response allows an early media session to be established prior to the call being answered, for example, to hear a ring tone, busy tone or recorded announcement.

[0] = (Default) Disable. If the device sends a 183 response with SDP (due to a received ISDN Progress or Proceeding with PI messages, i.e., a ring tone, busy tone or recorded announcement played to the ISDN side) and an Alerting message is then received from the ISDN side (with or without Progress Indicator), the device also sends a 180 Ringing response to the caller. Therefore, in this case, early media is played to the ISDN side and then the ringback tone is played by the IP PBX.
[1] = Enable. If the device sends a 183 response with SDP (due to a received ISDN Progress or Proceeding with PI messages) and an Alerting message is then received from the ISDN side (with or without Progress Indicator), the device doesn't send a 180 Ringing response to the caller and the voice channel remains open. Therefore, in this case, early media is played to the ISDN side and a ringback tone is not played by the IP PBX.

Note:

The parameter is applicable only to digital interfaces.
The parameter is applicable only if the [EnableEarlyMedia] parameter is set to 1 (i.e., enabled).

'183 Message Behavior'

configure voip > sip-definition settings > 183-msg-behavior

[SIP183Behaviour]

[0] Progress = (Default)
[1] Alert =

Note: The parameter is applicable only to the Gateway application.

[ReleaseIP2ISDNCallOnProgressWithCause]

Typically, if an Q.931 Progress message with a Cause is received from the PSTN for an outgoing IP-to-ISDN call and the [EnableEarlyMedia] parameter is set to 1 (i.e., the Early Media feature is enabled), the device interworks the Progress to 183 + SDP to enable the originating party to hear the PSTN announcement about the call failure. Conversely, if EnableEarlyMedia is set to 0, the device disconnects the call by sending a SIP 4xx response to the originating party. However, if the [ReleaseIP2ISDNCallOnProgressWithCause] parameter is set to 1, then the device sends a SIP 4xx response even if the [EnableEarlyMedia] parameter is set to 1.

[0] = (Default) If a Progress with Cause message is received from the PSTN for an outgoing IP-to-ISDN call, the device doesn't disconnect the call by sending a SIP 4xx response to the originating party.
[1] = The device sends a SIP 4xx response when the [EnableEarlyMedia] parameter is set to 0.
[2] = The device always sends a SIP 4xx response, even if he [EnableEarlyMedia] parameter is set to 1.

Note: The parameter is applicable only to digital interfaces.

'Session-Expires Time'

configure voip > sip-definition settings > session-expires-time

[SIPSessionExpires]

Defines the numerical value sent in the Session-Expires header in the first SIP INVITE request or response (if the call is answered).

The valid range is 1 to 86,400 sec. The default is 0 (i.e., the Session-Expires header is disabled).

Note: The parameter is applicable only to the Gateway application.

'Minimum Session-Expires'

configure voip > sip-definition settings > min-session-expires

[MinSE]

Defines the time (in seconds) in the SIP Min-SE header. The header defines the minimum time that the user agent refreshes the session.

The valid range is 10 to 100,000. The default is 90.

Note: The parameter is applicable only to the Gateway application.

'Session Expires Disconnect Time'

configure voip > sip-definition settings > sess-exp-disc-time

[SessionExpiresDisconnectTime]

Defines a session expiry timeout.

The new session expiry timeout is calculated by subtracting the configured value from the original timeout as specified in the Session-Expires header. However, the new timeout must be greater than or equal to one-third (1/3) of the Session-Expires value. If the refresher doesn't send a refresh request within the new timeout, the device disconnects the session (i.e., sends a SIP BYE).

For example, if you configure the parameter to 32 seconds and the Session-Expires value is 180 seconds, the session timeout occurs 148 seconds (i.e., 180 minus 32) after the last session refresh. If the Session-Expires header value is 90 seconds, the timeout occurs 60 seconds after the last refresh. This is because 90 minus 32 is 58 seconds, which is less than one third of the Session-Expires value (i.e., 60/3 is 30, and 90 minus 30 is 60).

The valid range is 0 to 32 (in seconds). The default is 32.

Note: The parameter is applicable only to the Gateway application.

'Session Expires Method'

configure voip > sip-definition settings > session-exp-method

[SessionExpiresMethod]

Defines the SIP method used for session-timer updates.

[0] Re-INVITE = (Default) Uses re-INVITE messages for session-timer updates.
[1] UPDATE = Uses UPDATE messages.

Note:

The parameter is applicable only to the Gateway application.
The device can receive session-timer refreshes using both methods.
The UPDATE message used for session-timer is excluded from the SDP body.

[RemoveToTagInFailureResponse]

Determines whether the device removes the ‘to’ header tag from final SIP failure responses to INVITE transactions.

[0] = (Default) Do not remove tag.
[1] = Remove tag.

[EnableRTCPAttribute]

Enables the use of the 'rtcp' attribute in the outgoing SDP.

[0] = Disable (default)
[1] = Enable

Note: The parameter is applicable only to the Gateway application.

[OPTIONSUserPart]

Defines the user part value of the Request-URI for outgoing SIP OPTIONS requests. If no value is configured, is used.

A special value is ‘empty’, indicating that no user part in the Request-URI (host part only) is used.

The valid range is a 30-character string. By default, this value is not defined.

'Trunk Status Reporting Mode'

configure voip > gateway digital settings > trunk-status-reporting

[TrunkStatusReportingMode]

Enables the device to not respond to received SIP OPTIONS messages from, and/or not to send keep-alive messages to, a proxy server associated with Trunk Group ID 1 if all its member trunks are down.

[0] Disable = (Default) Device responds to SIP OPTIONS messages from, and sends keep-alive messages to, a proxy server associated with Trunk Group ID 1 if all its member trunks are down.
[1] Don’t reply OPTIONS = The device doesn't respond to SIP OPTIONS received from the proxy associated with Trunk Group 1 when all its trunks are down.
[2] Don’t send Keep-Alive = The device doesn't send keep-alive messages to the proxy associated with Trunk Group 1 when all its trunks are down.
[3] Don’t Reply and Send = Both options [1] and [2] are applied.

Note:

The parameter is applicable only to digital interfaces.
When the parameter is set to not respond to SIP OPTIONS received from the proxy, it is applicable only if the OPTIONS message doesn't include a user part in the Request-URI.
The proxy server is determined by the Proxy Set that is associated with the Serving IP Group of the Trunk Group in the Trunk Group Settings table.

'TDM Over IP Minimum Calls For Trunk Activation'

[TDMOverIPMinCallsForTrunkActivation]

Defines the minimal number of SIP dialogs that must be established when using TDM Tunneling, for the specific trunk to be considered active.

When using TDM Tunneling, if calls from this defined number of B-channels pertaining to a specific Trunk fail (i.e., SIP dialogs are not correctly set up), an AIS alarm is sent on this trunk toward the PSTN and all current calls are dropped. The originator gateway continues the INVITE attempts. When this number of calls succeed (i.e., SIP dialogs are correctly set up), the AIS alarm is cleared.

The valid range is 0 to 31. The default is 0 (i.e., don't send AIS alarms).

Note: TDM Tunneling is applicable only to E1/T1 interfaces.

[TDMoIPInitiateInviteTime]

Defines the time (in msec) between the first INVITE issued within the same trunk when implementing the TDM tunneling application.

The valid value range is 500 to 1,000. The default is 500.

Note: TDM Tunneling is applicable only to E1/T1 interfaces.

[TDMoIPInviteRetryTime]

Defines the time (in msec) between call release and a new INVITE when implementing the TDM tunneling application.

The valid value range is 10,000 to 20,000. The default is 10,000.

Note: TDM Tunneling is applicable only to E1/T1 interfaces.

'Fax Signaling Method'

fax-sig-method

[IsFaxUsed]

Global parameter defining the SIP signaling method for establishing and transmitting a fax session when the device detects a fax.

You can also configure this feature per specific calls, using IP Profiles ('Fax Signaling Method' parameter) and Tel Profiles ('Fax Signaling Method' parameter). For a detailed description of the parameter, see Configuring IP Profiles and Configuring Tel Profiles.

Note: If you configure this feature for a specific IP Profile or Tel Profile, the device ignores this global parameter for calls associated with the IP Profile or Tel Profile.

fax-vbd-behvr

[FaxVBDBehavior]

Determines the device's fax transport behavior when G.711 VBD coder is negotiated at call start.

[0] = (Default) If the device is configured with a VBD coder (see the [CodersGroup] parameter) and is negotiated OK at call start, then both fax and modem signals are sent over RTP using the bypass payload type (and no mid-call VBD or T.38 Re-INVITEs occur).
[1] = If the [IsFaxUsed] parameter is set to 1, the channel opens with the [FaxTransportMode] parameter set to 1 (relay). This is required to detect mid-call fax tones and to send T.38 Re-INVITE messages upon fax detection. If the remote party supports T.38, the fax is relayed over T.38.

Note:

If VBD coder negotiation fails at call start and if the [IsFaxUsed] parameter is set to 1 (or 3), then the channel opens with the [FaxTransportMode] parameter set to 1 (relay) to allow future detection of fax tones and sending of T.38 Re-INVITES. In such a scenario, the [FaxVBDBehavior] parameter has no effect.
This feature can be used only if the remote party supports T.38 fax relay; otherwise, the fax fails.

[NoAudioPayloadType]

Defines the payload type of the outgoing SDP offer.

The valid value range is 96 to 127 (dynamic payload type). The default is 0 (i.e. NoAudio is not supported). For example, if set to 120, the following is added to the INVITE SDP:

a=rtpmap:120 NoAudio/8000\r\n

Note: For incoming SDP offers, NoAudio is always supported.

'SIP Transport Type'

configure voip > sip-definition settings > app-sip-transport-type

[SIPTransportType]

Determines the default transport layer for outgoing SIP calls initiated by the device.

[0] UDP (default)
[1] TCP
[2] TLS (SIPS)

Note:

It's recommended to use TLS for communication with a SIP Proxy and not for direct device-to-device communication.
For received calls (i.e., incoming), the device accepts all these protocols.

'Display Default SIP Port'

configure voip > sip-definition settings > display-default-sip-port

[DisplayDefaultSIPPort]

Enables the device to add the default SIP port 5060 (UDP/TCP) or 5061 (TLS) to outgoing messages that are received without a port. This condition also applies to manipulated messages where the resulting message has no port number. The device adds the default port number to the following SIP headers: Request-Uri, To, From, P-Asserted-Identity, P-Preferred-Identity, and P-Called-Party-ID. If the message is received with a port number other than the default, for example, 5070, the port number is not changed.

An example of a SIP From header with the default port is shown below:

From: <sip:+4000@10.8.4.105:5060;user=phone>;tag=f25419a96a;epid=009FAB8F3E

[0] Disable (default)
[1] Enable

'SIPS'

configure voip > sip-definition settings > enable-sips

[EnableSIPS]

Enables secured SIP (SIPS URI) connections over multiple hops.

[0] Disable (default)
[1] Enable

When the [SIPTransportType] parameter is set to 2 (i.e., TLS) and the parameter [EnableSIPS] is disabled, TLS is used for the next network hop only. When the [SIPTransportType] parameter is set to 2 or 1 (i.e., TCP or TLS) and [EnableSIPS] is enabled, TLS is used through the entire connection (over multiple hops).

Note: If the parameter is enabled and the [SIPTransportType] parameter is set to 0 (i.e., UDP), the connection fails.

'TCP/TLS Connection Reuse'

tcp-conn-reuse

[EnableTCPConnectionReuse]

Enables the reuse of an established TCP or TLS connection between the device and a SIP user agent (UA) for subsequent SIP requests sent to the UA. Any new out-of-dialog requests (e.g., INVITE or REGISTER) use the same secured connection. One of the benefits of enabling the parameter is that it may improve performance by eliminating the need for additional TCP/TLS handshakes with the UA, allowing sessions to be established rapidly.

[0] Disable = The device uses a new TCP or TLS connection with the UA.
[1] Enable = (Default) The device uses the same TCP or TLS connection for all SIP requests with the UA.

Note:

For SIP responses, the device always uses the same TCP/TLS connection, regardless of the parameter settings.

'Fake TCP Alias'

configure voip > sip-definition settings > fake-tcp-alias

[FakeTCPalias]

Enables the reuse of the same TCP/TLS connection for sessions with the same user even if the 'alias' parameter is not present in the SIP Via header of the initial INVITE.

[0] Disable = (Default) TCP/TLS connection reuse occurs only if the 'alias' parameter is present in the Via header of the initial INVITE (according to RFC 5923).
[1] Enable = Enables the reuse of TCP/TLS connections regardless of the presence of the 'alias' parameter.

Note: To enable TCP/TLS connection reuse, see the [EnableTCPConnectionReuse] parameter.

'Reliable Connection Persistent Mode'

configure voip > sip-definition settings > reliable-conn-persistent

[ReliableConnectionPersistentMode]

Enables all reusable TCP/TLS (reliable) connections to be persistent (i.e., not released).

When sending a SIP message, the device’s reliable connection reuse policy determines if current connections to the specific destination are reused.

Persistent connections ensure less network traffic due to fewer setting up and tearing down of reliable connections and reduced latency on subsequent requests because there is no need for initial TCP handshakes. Persistent connections may reduce the number of costly TLS handshakes to establish security associations, in addition to the initial TCP connection setup.

[0] Disable = (Default) The device releases all reliable connections that aren't being used. However, if the destination is a Proxy server (configured in the Proxy Sets table), the reliable connection is always persistent, regardless of the parameter's settings.
[1] Enable = The device makes reusable reliable connections to all destinations persistent and doesn't release them (see note below). A persistent connection stays open even when it's no longer in use (i.e., not used by any SIP dialog or transaction, and isn't associated with a registered user).

Note:

The device releases unnecessary persistent TLS connections to prevent them from accumulating and reaching the device's maximum number of supported TLS connections (refer to the document Release Notes). If the number of incoming TLS connections exceeds 80% of the maximum, the device closes incoming TLS connections that aren’t in use (i.e., no active SIP dialogs and not associated with a registered user) and that are kept open only because they are persistent.
Similar to the above note, the device releases reliable (TCP/TLS) connections that aren’t in use and are kept open only because they are persistent, when reaching 80% of the maximum number of supported reliable connections.
The device sends the SNMP alarm acTLSSocketsLimitAlarm when the number of incoming TLS connections exceeds 95% of the maximum TLS connections supported by the device.
Connection reuse depends on the [EnableTCPConnectionReuse] parameter; for incoming connections, reuse also depends on SIP message characteristics (presence of Via header’s ‘alias’ parameter in initial request).

'TCP Timeout'

configure voip > sip-definition settings > tcp-timeout

[SIPTCPTimeout]

Defines the Timer B (INVITE transaction timeout timer) and Timer F (non-INVITE transaction timeout timer), as defined in RFC 3261, when the SIP transport type is TCP.

The valid range is 0 to 60 sec. The default is 0, which means that the parameter's value is set to 64 multiplied by the value of the [SipT1Rtx] parameter. For example, if you configure [SipT1Rtx] to 500 msec (0.5 sec) and leave the [SIPTCPTimeout] parameter at its default value (0), the actual value of [SIPTCPTimeout] is 32 sec (64 x 0.5 sec).

'SIP Destination Port'

configure voip > sip-definition settings > sip-dst-port

[SIPDestinationPort]

Defines the SIP destination port for sending initial SIP requests.

The valid range is 1 to 65534. The default port is 5060.

Note: SIP responses are sent to the port specified in the Via header.

'Use user=phone in SIP URL'

configure voip > sip-definition settings > user-phone-in-url

[IsUserPhone]

Defines if the 'user=phone' string is added to the SIP URI and SIP To header.

[0] No
[1] Yes (default)

Note: The parameter is applicable only to the Gateway application.

'Use user=phone in From Header'

configure voip > sip-definition settings > user-phone-in-from

[IsUserPhoneInFrom]

Defines if the 'user=phone' string is added to the From and Contact SIP headers.

[0] No (default)
[1] Yes

Note: The parameter is applicable only to the Gateway application.

'Use Tel URI for Asserted Identity'

configure voip > sip-definition settings > uri-for-assert-id

[UseTelURIForAssertedID]

Defines the format of the URI in the P-Asserted-Identity and P-Preferred-Identity headers.

[0] Disable = (Default) The format is 'sip:'.
[1] Enable = The format is 'tel:'.

configure voip > sip-definition settings > p-preferred-id-list

[PPreferredIdListMode]

Defines the number of P-Preferred-Identity SIP headers included in the outgoing SIP message when the header contains multiple values.

[0] = (Default) The device includes multiple P-Preferred-Identity SIP headers in the outgoing message, for example:
Incoming message containing a P-Preferred-Identity header with multiple values:
P-Preferred-Identity: <sip:someone@test.org>,<tel:+123456789>
Outgoing message sent with multiple P-Preferred-Identity headers, each with a value:
P-Preferred-Identity: <sip:someone@test.org>
P-Preferred-Identity: <tel:+123456789>
[1] = The device includes only one P-Preferred-Identity header in the outgoing message, for example:
Incoming message containing multiple P-Preferred-Identity headers:
P-Preferred-Identity: <sip:someone@test.org>
P-Preferred-Identity: <tel:+123456789>
Outgoing message sent with a single P-Preferred-Identity header containing the multiple values:
P-Preferred-Identity: <sip:someone@test.org>,<tel:+123456789>

Note:

If more than two P-Preferred-Identity headers are received in the incoming message, the device keeps the first two headers (if configured to 0) or the first header (if configured to 1), and removes the others in the outgoing message.
The parameter is applicable only to the SBC application.

'Tel to IP No Answer Timeout'

configure voip > gateway advanced > tel2ip-no-ans-timeout

[IPAlertTimeout]

Defines the time (in seconds) that the device waits for a 200 OK response from the called party (IP side) after sending an INVITE message, for Tel-to-IP calls. If the timer expires, the call is released.

The valid range is 0 to 3600. The default is 180.

'Remote Party ID'

configure voip > sip-definition settings > remote-party-id

[EnableRPIheader]

Enables Remote-Party-Identity headers for calling and called numbers for Tel-to-IP calls.

[0] Disable (default).
[1] Enable = Remote-Party-Identity headers are generated in SIP INVITE messages for both called and calling numbers.

'History-Info Header'

configure voip > sip-definition settings > hist-info-hdr

[EnableHistoryInfo]

Enables usage of the SIP History-Info header.

[0] Disable (default)
[1] Enable

User Agent Client (UAC) Behavior:

Initial request: The History-Info header is equal to the Request-URI. If a PSTN Redirect number is received, it is added as an additional History-Info header with an appropriate reason.
Upon receiving the final failure response, the device copies the History-Info as is, adds the reason of the failure response to the last entry, and concatenates a new destination to it (if an additional request is sent). The order of the reasons is as follows:
a. Q.850 Reason
b. SIP Reason
c. SIP Response code
Upon receiving the final response (success or failure), the device searches for a Redirect reason in the History-Info (i.e., 3xx/4xx SIP reason). If found, it is passed to ISDN according to the following table:

SIP Reason Code

ISDN Redirecting Reason

302 - Moved Temporarily

Call Forward Universal (CFU)

408 - Request Timeout

Call Forward No Answer (CFNA)

480 - Temporarily Unavailable

487 - Request Terminated

486 - Busy Here

Call Forward Busy (CFB)

600 - Busy Everywhere

If history reason is a Q.850 reason, it is translated to the SIP reason (according to the SIP-ISDN tables) and then to ISDN Redirect reason according to the table above.

User Agent Server (UAS) Behavior:

The History-Info header is sent only in the final response.
Upon receiving a request with History-Info, the UAS checks the policy in the request. If a 'session', 'header', or 'history' policy tag is found, the (final) response is sent without History-Info; otherwise, it is copied from the request.

Note: The parameter is applicable only to digital interfaces.

'Use SIP tgrp Information'

configure voip > sip-definition settings > use-tgrp-inf

[UseSIPTgrp]

Enables the device to add the SIP 'tgrp' parameter to outgoing SIP message requests. This parameter specifies the Trunk Group to which the call belongs (according to RFC 4904). For example, the INVITE message below indicates that the call belongs to Trunk Group ID 1:

INVITE sip::+16305550100;tgrp=1;trunk-context=example.com@10.1.0.3;user=phone SIP/2.0

[0] Disable = (Default) The device doesn't use (and add) the 'tgrp' parameter.
[1] Send Only = The device adds the Trunk Group number or name (configured in the Trunk Group Settings table) as the 'tgrp' parameter value in the Contact header of outgoing INVITE messages. If a Trunk Group number or name is not associated with the call, the device doesn't add the 'tgrp' parameter. If a 'tgrp' value is present in incoming messages, the device ignores it.
[2] Send & Receive = The functionality of outgoing SIP messages is identical to the functionality described for option Send Only. In addition, for incoming SIP INVITEs (IP-to-Tel), if the Request-URI includes the 'tgrp' parameter, the device routes the call according to that value (if possible). In the outgoing SIP INVITE (Tel-to-IP call), the device adds "tgrp=<source trunk group ID>;trunk-context=<gateway IP address>” to the Contact header. The <source trunk group ID> is the Trunk Group ID where incoming calls from Tel is received. For IP-to-Tel calls, the SIP 200 OK device's response contains “tgrp=<destination trunk group ID>;trunk-context=<gateway IP address>”. The <destination trunk group ID> is the Trunk Group ID used for outgoing Tel calls. You can configure the <gateway IP address> in “trunk-context”, using the [SIPGatewayName] parameter.
[3] Hotline = Interworks the hotline "Off Hook Indicator" parameter between SIP and ISDN. This option is applicable only to digital interfaces.
IP-to-ISDN calls:
The device interworks the SIP 'tgrp=hotline' parameter (received in INVITE) to ISDN Setup with the Off Hook Indicator IE of “Voice”, and “Speech” Bearer Capability IE. Note that the Off Hook Indicator IE is described in UCR 2008 specifications.
The device interworks the SIP 'tgrp=hotline-ccdata' parameter (received in INVITE) to ISDN Setup with an Off Hook Indicator IE of “Data”, and with “Unrestricted 64k” Bearer Capability IE. The following is an example of an INVITE with 'tgrp=hotline-ccdata':

INVITE sip:1234567;tgrp=hotline-ccdata;trunk-context=dsn.mil@example.com

ISDN-to-IP calls:
The device interworks ISDN Setup with an Off Hook Indicator of “Voice” to SIP INVITE with 'tgrp=hotline;trunk-context=dsn.mil' in the Contact header.
The device interworks ISDN Setup with an Off Hook indicator of “Data” to SIP INVITE with 'tgrp=hotline-ccdata;trunk-context=dsn.mil' in the Contact header.
If ISDN Setup doesn't contain an Off Hook Indicator IE and the Bearer Capability IE contains “Unrestricted 64k”, the outgoing INVITE includes 'tgrp=ccdata;trunk-context=dsn.mil'. If the Bearer Capability IE contains “Speech”, the INVITE in this case doesn't contain 'tgrp' and 'trunk-context' parameters.
[4] Hotline Extended = Interworks the ISDN Setup message’s hotline "OffHook Indicator" Information Element (IE) to SIP INVITE’s Request-URI and Contact headers. (Note: For IP-to-ISDN calls, the device handles the call as described in option Hotline.) This option is applicable only to digital interfaces.
The device interworks ISDN Setup with an Off Hook Indicator of “Voice” to SIP INVITE Request-URI and Contact header with 'tgrp=hotline;trunk-context=dsn.mil'.
The device interworks ISDN Setup with an Off Hook indicator of “Data” to SIP INVITE Request-URI and Contact header with 'tgrp=hotline-ccdata;trunk-context=dsn.mil'.
If ISDN Setup doesn't contain an Off Hook Indicator IE and the Bearer Capability IE contains “Unrestricted 64k”, the outgoing INVITE Request-URI and Contact header includes 'tgrp=ccdata;trunk-context=dsn.mil'. If the Bearer Capability IE contains “Speech”, the INVITE in this case doesn't contain tgrp and trunk-context parameters.
[5] Send Only Including Register = The device adds the 'tgrp', 'trunk-context', and 'user=phone' parameters to the Contact header of outgoing SIP INVITE and REGISTER requests.
[6] Send & Receive Including Register = The device adds the 'tgrp', 'trunk-context', and 'user=phone' parameters to the Contact header of outgoing SIP INVITE and REGISTER requests. In addition, the device uses these parameters if they are present in the Request-URI of incoming INVITE requests.

Note: IP-to-Tel configuration (see Configuring IP-to-Tel Routing Rules) overrides the 'tgrp' parameter in incoming INVITE messages.

configure voip > gateway routing settings > tgrp-routing-prec

[TGRProutingPrecedence]

Defines the precedence method for IP-to-Tel call routing - according to the IP-to-Tel Routing table or the SIP 'tgrp' parameter.

[0] = (Default) IP-to-Tel routing is determined by the IP-to-Tel Routing table (see Configuring IP-to-Tel Routing Rules). If a matching routing rule is not found, the device uses the Trunk Group parameters for routing the call.
[1] = The device first places precedence on the 'tgrp' parameter for IP-to-Tel routing. If the received Request-URI in the INVITE message doesn't contain the 'tgrp' parameter, or if the Trunk Group number is not defined, the device uses the IP-to-Tel Routing table to route the call.

The following example shows an INVITE Request-URI with the 'tgrp' parameter, indicating that the IP call should be routed to Trunk Group 7:

INVITE sip:200;tgrp=7;trunk-context=example.com@10.33.2.68;user=phone SIP/2.0

Note:

To enable routing based on the SIP 'tgrp' parameter, see the [UseSIPTgrp] parameter.
Instead of the 'tgrp' parameter for IP-to-Tel routing, you can use the SIP 'dtg' parameter (see the [UseBroadsoftDTG] parameter).

configure voip > sip-definition settings > use-dtg

[UseBroadsoftDTG]

Defines if the device uses the SIP 'dtg' parameter for routing IP-to-Tel calls to a specific Trunk Group.

[0] = Disable (default)
[1] = Enable

When enabled, if the Request-URI in the received SIP INVITE includes the 'dtg' parameter, the device routes the call to the Trunk Group according to its value. The parameter is used instead of the 'tgrp' and 'trunk-context' parameters. The 'dtg' parameter appears in the INVITE Request-URI (and in the To header). For example, the following received SIP message routes the call to Trunk Group ID 56:

INVITE sip:123456@192.168.1.2;dtg=56;user=phone SIP/2.0

Note: If the Trunk Group is not found based on the 'dtg' parameter, the device uses the IP-to-Tel Routing table to route the call to the appropriate Trunk Group.

'GRUU'

configure voip > sbc settings > gruu

[EnableGRUU]

Determines whether the Globally Routable User Agent URIs (GRUU) mechanism is used, according to RFC 5627. This is used for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog.

[0] Disable (default)
[1] Enable

A GRUU is a SIP URI that routes to an instance-specific UA and can be reachable from anywhere. There are a number of contexts in which it is desirable to have an identifier that addresses a single UA (using GRUU) rather than the group of UA’s indicated by an Address of Record (AOR). For example, in call transfer where user A is talking to user B, and user A wants to transfer the call to user C. User A sends a REFER to user C:

REFER sip:C@domain.com SIP/2.0

From: sip:A@domain.com;tag=99asd

To: sip:C@domain.com

Refer-To: (URI that identifies B's UA)

The Refer-To header needs to contain a URI that user C can use to place a call to user B. This call needs to route to the specific UA instance that user B is using to talk to user A. User B should provide user A with a URI that has to be usable by anyone. It needs to be a GRUU.

Obtaining a GRUU: The mechanism for obtaining a GRUU is through registrations. A UA can obtain a GRUU by generating a REGISTER request containing a Supported header field with the value “gruu”. The UA includes a “+sip.instance” Contact header parameter of each contact for which the GRUU is desired. This Contact parameter contains a globally unique ID that identifies the UA instance. The global unique ID is created from one of the following:
If the REGISTER is per the device’s client (endpoint), it is the MAC address concatenated with the phone number of the client.
If the REGISTER is per device, it is the MAC address only.
When using TP, “User Info” can be used for registering per endpoint. Thus, each endpoint can get a unique id – its phone number. The globally unique ID in TP is the MAC address concatenated with the phone number of the endpoint.

If the remote server doesn’t support GRUU, it ignores the parameters of the GRUU. Otherwise, if the remote side also supports GRUU, the REGISTER responses contain the “gruu” parameter in each Contact header. The parameter contains a SIP or SIPS URI that represents a GRUU corresponding to the UA instance that registered the contact. The server provides the same GRUU for the same AOR and instance-id when sending REGISTER again after registration expiration. RFC 5627 specifies that the remote target is a GRUU target if its’ Contact URL has the "gr" parameter with or without a value.

Using GRUU: The UA can place the GRUU in any header field that can contain a URI. It must use the GRUU in the following messages: INVITE request, its 2xx response, SUBSCRIBE request, its 2xx response, NOTIFY request, REFER request and its 2xx response.

[IsCiscoSCEMode]

Determines whether a Cisco gateway exists at the remote side.

[0] = (Default) No Cisco gateway exists at the remote side.
[1] = A Cisco gateway exists at the remote side.

When a Cisco gateway exists at the remote side, the device must set the value of the 'annexb' parameter of the fmtp attribute in the SDP to 'no'. This logic is used if the coder is enabled for Silenced Suppression. In this case, Silence Suppression is used on the channel but not declared in the SDP.

Note:

The parameter is applicable only to the Gateway application.
The [IsCiscoSCEMode] parameter is applicable only when the selected coder is G.729.

'User-Agent Information'

configure voip > sip-definition settings > user-agent-info

[UserAgentDisplayInfo]

Defines the string that is used in the SIP User-Agent and Server response headers. When configured, the string <UserAgentDisplayInfo value>/software version' is used, for example:

User-Agent: myproduct/7.40A.600.203

If not configured, the default string, "<product-name>/<<software version>>" is used, for example:

User-Agent: AudioCodes-Sip-Gateway/<swver>

The maximum string length is 50 characters.

Note: The software version number and preceding forward slash (/) cannot be modified. Therefore, it is recommended not to include a forward slash in the parameter's value (to avoid two forward slashes in the SIP header, which may cause problems).

'SDP Session Owner'

configure voip > sip-definition settings > sdp-session-owner

[SIPSDPSessionOwner]

Defines the value of the Owner line ('o' field) in outgoing SDP messages.

The valid range is a string of up to 39 characters. The default is "AudioCodesGW".

For example:

o=AudioCodesGW 1145023829 1145023705 IN IP4 10.33.4.126

Note: The parameter is applicable only to the SBC application when the device creates a new SIP message (and SDP) such as when the device plays a ringback tone. The parameter is not applicable to SIP messages that the device receives from one end and sends to another (i.e., doesn't modify the SDP's 'o' field).

configure voip > sip-definition settings > sdp-ver-nego

[EnableSDPVersionNegotiation]

Enables the device to ignore new SDP re-offers (from the media negotiation perspective) in certain scenarios (such as session expires). According to RFC 3264, once an SDP session is established, a new SDP offer is considered a new offer only when the SDP origin value is incremented. In scenarios such as session expires, SDP negotiation is irrelevant and thus, the origin field is not changed.

Even though some SIP devices don’t follow this behavior and don’t increment the origin value even in scenarios where they want to re-negotiate, the device can assume that the remote party operates according to RFC 3264, and in cases where the origin field is not incremented, the device doesn't re-negotiate SDP capabilities.

[0] Disable = (Default) The device negotiates any new SDP re-offer, regardless of the origin field.
[1] Enable = The device negotiates only an SDP re-offer with an incremented origin field.

configure voip > gateway advanced > use-conn-sdpses-or-media

[GwSDPConnectionMode]

Defines how the device displays the Connection ("c=") line in the SDP Offer/Answer model.

[0] = (Default) The Connection ("c=") line is displayed as follows:
Offer: In the session description only.
Answer: In the session description and in each media ("m=") description.
[1] = For Offer and Answer, the Connection ("c=") line is displayed only in the session description; not in any media ("m=") descriptions.
[2] = The Connection ("c=") line is displayed only in media ("m=") descriptions.

Note: The parameter is applicable only to the Gateway application.

'Subject'

configure voip > sip-definition settings > usr-def-subject

[SIPSubject]

Defines the Subject header value in outgoing INVITE messages. If not specified, the Subject header isn't included (default).

The maximum length is up to 50 characters.

configure voip > sip-definition settings > coder-priority-nego

[CoderPriorityNegotiation]

Defines the priority for coder negotiation in the incoming SDP offer, between the device's or remote UA's coder list.

[0] = (Default) Coder negotiation is given higher priority to the remote UA's list of supported coders.
[1] = Coder negotiation is given higher priority to the device's (local) supported coders list.

Note: The parameter is applicable only to the Gateway application.

'Send All Coders on Retrieve'

configure voip > gateway dtmf-supp-service supp-service-settings > send-all-cdrs-on-rtrv

[SendAllCodersOnRetrieve]

Enables coder re-negotiation in the sent re-INVITE for retrieving an on-hold call.

[0] Disable = (Default) Sends only the initially chosen coder when the call was first established and then put on-hold.
[1] Enable = Includes all supported coders in the SDP of the re-INVITE sent to the call made un-hold (retrieved). The used coder is therefore, re-negotiated.

The parameter is useful in the following call scenario example:

1. Party A calls party B and coder G.711 is chosen.
2. Party B is put on-hold while Party A blind transfers Party B to Party C.
3. Party C answers and Party B is made un-hold. However, as Party C supports only G.729 coder, re-negotiation of the supported coder is required.

Note: The parameter is applicable only to the Gateway application.

'Multiple Packetization Time Format'

configure voip > sip-definition settings > mult-ptime-format

[MultiPtimeFormat]

Determines whether the 'mptime' attribute is included in the outgoing SDP.

[0] None = (Default) Disabled.
[1] PacketCable = Includes the 'mptime' attribute in the outgoing SDP - PacketCable-defined format.

The mptime' attribute enables the device to define a separate packetization period for each negotiated coder in the SDP. The 'mptime' attribute is only included if the parameter is enabled even if the remote side includes it in the SDP offer. Upon receipt, each coder receives its 'ptime' value in the following precedence: from 'mptime' attribute, from 'ptime' attribute, and then from default value.

Note: The parameter is applicable only to the Gateway application.

configure voip > sip-definition settings > enable-ptime

[EnablePtime]

Defines if the 'ptime' attribute is included in the SDP.

[0] = Remove the 'ptime' attribute from SDP.
[1] = (Default) Include the 'ptime' attribute in SDP.

'3xx Behavior'

3xx-behavior

[3xxBehavior]

Determines the device's behavior regarding call identifiers when a 3xx response is received for an outgoing INVITE request. The device can use the same call identifiers (Call-ID, To, and From tags) or change them in the new initiated INVITE.

[0] Forward = (Default) Use different call identifiers for a redirected INVITE message.
[1] Redirect = Use the same call identifiers in the new INVITE as the original call.

'P-Charging Vector'

p-charging-vector

[EnablePChargingVector]

Enables the inclusion of the P-Charging-Vector header to all outgoing INVITE messages.

[0] Disable (default)
[1] Enable

Note: The parameter is applicable only to the Gateway application.

configure voip > sip-definition settings > retry-after-mode

[RetryAfterMode]

Defines the device’s behavior when it receives a SIP 503 (Service Unavailable) containing a Retry-After header, in response to a SIP message (e.g., REGISTER) sent to a proxy server.

In certain scenarios (depending on the value of this parameter), the device considers the proxy as offline (down) for the number of seconds specified in the Retry-After header. During this timeout, the device doesn't send any SIP messages to the proxy. This condition is indicated in the syslog message as "server is now Unavailable - setting Retry-After timer to x secs".

[1] = (Default) Handle Locally. The device considers the proxy as offline regardless of the type of SIP message sent to the proxy for which the 503 response was received.
[0] = Transparent. The behavior depends on the type of SIP message sent to the proxy for which the 503 response was received:
SIP OPTIONS message: The device considers the proxy as offline.
SIP REGISTER message generated (created) by the device: The device doesn't send REGISTER messages to the proxy for this specific registration process (i.e., Accounts table or SBC User Information table) during the timeout specified in the Retry-After header of the 503 response. However, the device considers the proxy as online and therefore, it continues sending traffic of other entities to the proxy.
All other SIP dialogs (e.g., INVITE): The device ignores the Retry-After header and forwards the 503 response transparently to the other user agent.

'Retry-After Time'

configure voip > sip-definition settings > retry-aftr-time

[RetryAfterTime]

Defines the time (in seconds) used in the Retry-After header when a 503 (Service Unavailable) response is generated by the device.

The time range is 0 to 3,600. The default is 0.

'Fake Retry After'

fake-retry-after

[FakeRetryAfter]

Defines if the device, upon receiving a SIP 503 response without a Retry-After header, behaves as if the 503 response included a Retry-After header and with the period (in seconds) specified by the parameter.

[0] Disable (default)
Any positive value (in seconds) for defining the period

When enabled, this feature allows the device to operate with Proxy servers that do not include the Retry-After SIP header in SIP 503 (Service Unavailable) responses to indicate an unavailable service.

The Retry-After header is used with the 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting SIP client. The device maintains a list of available proxies, by using the Keep-Alive mechanism. The device checks the availability of proxies by sending SIP OPTIONS every keep-alive timeout to all proxies.

If the device receives a SIP 503 response to an INVITE, it also marks that the proxy is out of service for the defined "Retry-After" period.

'P-Associated-URI Header'

p-associated-uri-hdr

[EnablePAssociatedURIHeader]

Determines the device usage of the P-Associated-URI header. This header can be received in 200 OK responses to REGISTER requests. When enabled, the first URI in the P-Associated-URI header is used in subsequent requests as the From/P-Asserted-Identity headers value.

[0] Disable (default)
[1] Enable

Note: P-Associated-URIs in registration responses is handled only if the device is registered per endpoint (using the User Information file).

configure voip > gateway digital settings > format-dst-phone-number

[FormatDestPhoneNumber]

Defines if the destination phone number that the device sends to the Tel side (for IP-to-Tel calls), includes the user-part parameters (e.g., 'password' and 'phone-context') of the destination URI received in the incoming SIP INVITE message.

[0] = (Transparent) The device includes the user-part parameters (if exist) in the destination phone number sent to the Tel side.
[1] = (Default) The device excludes the user-part parameters and letters (if exist) from the destination phone number sent to the Tel side.

Note: The parameter is applicable only to the Gateway application.

'Source Number Preference'

configure voip > sip-definition settings > src-nb-preference

[SourceNumberPreference]

Defines the SIP header from which the source (calling) number is obtained in incoming INVITE messages.

If not configured or if any string other than "From" or "Pai2" is configured, the calling number is obtained from a specific header using the following logic:
a. P-Preferred-Identity header.
b. If the above header is not present, then the first P-Asserted-Identity header is used.
c. If the above header is not present, then the Remote-Party-ID header is used.
d. If the above header is not present, then the From header is used.
"From" = The calling number is obtained from the From header.
"Pai2" = The calling number is obtained using the following logic:
e. If a P-Preferred-Identity header is present, the number is obtained from it.
f. If no P-Preferred-Identity header is present and two P-Asserted-Identity headers are present, the number is obtained from the second P-Asserted-Identity header.
g. If only one P-Asserted-Identity header is present, the calling number is obtained from it.

Note:

The "From" and "Pai2" values are not case-sensitive.
Once a URL is selected, all the calling party parameters are set from this header. If P-Asserted-Identity is selected and the Privacy header has the value 'id', the calling number is assumed restricted.

'Enforce Media Order'

[EnforceMediaOrder]

Enables the device to include all previously negotiated media lines ('m=') within the current session in the SDP offer-answer exchange (RFC 3264).

[0] Disable (default)
[1] Enable

For example, assume a call (audio) has been established between two endpoints and one endpoint wants to subsequently send an image in the same call session. If the parameter is enabled, the endpoint includes the previously negotiated media type (i.e., audio) with the new negotiated media type (i.e., image) in its SDP offer:

v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 0 RTP/AVP 0
m=image 12345 udptl t38

In this example, if the parameter is disabled, the only ‘m=’ line included in the SDP is the newly negotiated media (i.e., image).

Note: The parameter is applicable only to the Gateway application.

configure voip > sip-definition settings > sec-call-src

[SecondCallingNumberSource]

Defines if the device sends a second source (calling) number, obtained from the incoming SIP INVITE message, to the Tel side.

The valid value is “P-Asserted” (without quotation marks). By default, no value is defined.

If the parameter is not configured to any value (i.e., default) or configured to any value other than "P-Asserted", the device doesn’t send a second source number. If the parameter is configured to "P-Asserted" and the incoming INVITE message contains a P-Asserted-Identity header(s), the device sends a second source number that is obtained from the first listed P-Asserted-Identity header in the message. If the message doesn’t include a P-Asserted-Identity header, the device sends a second source number that it obtains from the first source number (i.e., same number).

Note: The parameter is applicable only to the Gateway application.

'Source Header For Called Number'

configure voip > sip-definition settings > src-hdr-4-called-nb

[SelectSourceHeaderForCalledNumber]

Defines the SIP header from which the called (destination) number is obtained for IP-to-Tel calls.

[0] use RequestURI header = (Default) Obtains the destination number from the user part of the Request-URI.
[1] use To header = Obtains the destination number from the user part of the To header.
[2] use P-Called-Party-ID header = Obtains the destination number from the P-Called-Party-ID header.

Note: The parameter is applicable only to the Gateway application.

'Reason Header'

configure voip > sip-definition settings > reason-header

[EnableReasonHeader]

Enables the usage of the SIP Reason header.

[0] Disable
[1] Enable (default)

'Gateway Name'

configure voip > sip-definition settings > gw-name

[SIPGatewayName]

Defines a name for the device (e.g., device123.com), which is used as the host part for the SIP URI in the From header for outgoing messages. If not configured, the device's IP address is used instead (default).

The valid value is a string of up to 100 characters. By default, no value is defined.

Note:

Ensure that the parameter value is the one with which the proxy has been configured with to identify the device.
If you enable keep-alive by SIP OPTIONS messages with the proxy (see the Proxy Set parameter 'Proxy Keep-Alive'), you can configure, using the [UseGatewayNameForOptions] parameter, if the device's IP address, the proxy's IP address, or the device's name (configured by the [SIPGatewayName] parameter) is used in the keep-alive SIP OPTIONS messages (host part of the Request-URI).
The parameter can also be configured for an IP Group (in the IP Groups table).

configure voip > sip-definition settings > zero-sdp-behavior

[ZeroSDPHandling]

Determines the device's response to an incoming SDP that includes an IP address of 0.0.0.0 in the SDP's Connection Information field (i.e., "c=IN IP4 0.0.0.0").

[0] = (Default) Sets the IP address of the outgoing SDP's c= field to 0.0.0.0.
[1] = Sets the IP address of the outgoing SDP c= field to the IP address of the device. If the incoming SDP doesn’t contain the "a=inactive" line, the returned SDP contains the "a=recvonly" line.

'Delayed Offer'

configure voip > sip-definition settings > delayed-offer

[EnableDelayedOffer]

Determines whether the device sends the initial INVITE message with or without an SDP. Sending the first INVITE without SDP is typically done by clients for obtaining the far-end's full list of capabilities before sending their own offer. (An alternative method for obtaining the list of supported capabilities is by using SIP OPTIONS, which is not supported by every SIP agent.)

[0] Disable = (Default) The device sends the initial INVITE message with an SDP.
[1] Enable = The device sends the initial INVITE message without an SDP.

configure voip > sip-definition settings > digest-auth-uri-mode

[SIPDigestAuthorizationURIMode]

Defines if the device includes or excludes URI parameters for the Digest URI in the SIP Proxy-Authorization or Authorization headers of the request that the device sends in reply to a received SIP 401 (Unauthorized) or 407 (Proxy Authentication Required) response.

Below shows an example of a request with an Authorization header containing a Digest URI (shown in bold):

Authorization: Digest username="alice at AudioCodes.com",realm="AudioCodes.com",nonce="",response="",uri="sip:AudioCodes.com"

[0] = (Default) The device sends the request without a Digest URI.
[1] = The device sends the request with a Digest URI, which is set to the same value as the URI in the original Request-URI.

configure voip > sip-definition settings > crypto-life-time-in-sdp

[DisableCryptoLifeTimeInSDP]

Enables the device to send "a=crypto" lines without the lifetime parameter in the SDP. For example, if the SDP contains "a=crypto:12 AES_CM_128_HMAC_SHA1_80 inline:hhQe10yZRcRcpIFPkH5xYY9R1de37ogh9G1MpvNp|2^31", it removes the lifetime parameter "2^31".

[0] Disable (default)
[1] Enable

'AES-256 Encryption Key'

configure voip > sip-definition settings > encrypt-key-aes256

[EncryptKeyAES256]

Defines the AES-256 encryption key for encrypting (and decrypting) the SIP header value.

The valid value is a string of 32 characters. By default, no value is defined.

For more information, see Configuring SIP Header Value Encryption.

'Contact Restriction'

contact-restriction

[EnableContactRestriction]

Determines whether the device sets the Contact header of outgoing INVITE requests to ‘anonymous’ for restricted calls.

[0] Disable (default)
[1] Enable

configure voip > sip-definition settings > anonymous-mode

[AnonymousMode]

Defines if the device's IP address is used as the URI host part instead of "anonymous.invalid" in the INVITE's From header for Tel-to-IP calls.

[0] = (Default) If the device receives a call from the Tel with blocked caller ID, it sends an INVITE with
From: “anonymous”<anonymous@anonymous.invalid>
[1] = The device's IP address is used as the URI host part instead of "anonymous.invalid".

The parameter may be useful, for example, for service providers who identify their SIP Trunking customers by their source phone number or IP address, reflected in the From header of the SIP INVITE. Therefore, even customers blocking their Caller ID can be identified by the service provider. Typically, if the device receives a call with blocked Caller ID from the PSTN side (e.g., Trunk connected to a PBX), it sends an INVITE to the IP with a From header as follows: "From: “anonymous” <anonymous@anonymous.invalid>". This is in accordance with RFC 3325. However, when the parameter is set to 1, the device replaces the "anonymous.invalid" with its IP address.

configure voip > sip-definition settings > p-assrtd-usr-name

[PAssertedUserName]

Defines a 'representative number' (up to 50 characters) that is used as the user part of the Request-URI in the P-Asserted-Identity header of an outgoing INVITE for Tel-to-IP calls.

The default is null.

configure voip > sip-definition settings > use-aor-in-refer-to-header

[UseAORInReferToHeader]

Defines the source for the SIP URI set in the Refer-To header of outgoing REFER messages.

[0] = (Default) Use SIP URI from Contact header of the initial call.
[1] = Use SIP URI from To/From header of the initial call.

'User-Information Usage'

configure voip > sip-definition settings > user-inf-usage

[EnableUserInfoUsage]

Enables the usage of the User Information, which is loaded to the device in the User Information Auxiliary file. For more information on User Information, see User Information File.

[0] Disable (default)
[1] Enable

Note: For the parameter to take effect, a device restart is required.

configure voip > sip-definition settings > handle-reason-header

[HandleReasonHeader]

Determines whether the device uses the value of the incoming SIP Reason header for Release Reason mapping.

[0] = Disregard Reason header in incoming SIP messages.
[1] = (Default) Use the Reason header value for Release Reason mapping.

[EnableSilenceSuppInSDP]

Determines the device's behavior upon receipt of SIP Re-INVITE messages that include the SDP's 'silencesupp:off' attribute.

[0] = (Default) Disregard the 'silecesupp' attribute.
[1] = Handle incoming Re-INVITE messages that include the 'silencesupp:off' attribute in the SDP as a request to switch to the Voice-Band-Data (VBD) mode. In addition, the device includes the attribute 'a=silencesupp:off' in its SDP offer.

Note: The parameter is applicable only if the G.711 coder is used.

configure voip > sip-definition settings > rport-support

[EnableRport]

Enables the usage of the 'rport' parameter in the Via header.

[0] = Disabled (default)
[1] = Enabled

The device adds an 'rport' parameter to the Via header of each outgoing SIP message. The first Proxy that receives this message sets the 'rport' value of the response to the actual port from where the request was received. This method is used, for example, to enable the device to identify its port mapping outside a NAT.

If the Via header doesn't include the 'rport' parameter, the destination port of the response is obtained from the host part of the Via header.
If the Via header includes the 'rport' parameter without a port value, the destination port of the response is the source port of the incoming request.
If the Via header includes 'rport' with a port value (e.g., rport=1001), the destination port of the response is the port indicated in the 'rport' parmeter.

'Enable X-Channel Header'

configure voip > sip-definition settings > x-channel-header

[XChannelHeader]

Enables the device to add the SIP X-Channel header to outgoing SIP messages. The header provides information on the physical on which the call is received or sent.

[0] Disable = (Default) X-Channel header is not used.
[1] Enable = X-Channel header is generated by the device and sent in SIP INVITE requests and 180, 183, and 200 OK responses. The header includes the and the device's IP address, using the following syntax:

x-channel: ds/ds1-<digital Trunk number>/<>;IP=<device's IP address>

For example, the below shows a call on Trunk 1, channel 4 of the device with IP address 192.168.13.1:

x-channel: ds/ds1-1/4;IP=192.168.13.1

'Progress Indicator to IP'

configure voip > sip-definition settings > prog-ind-2ip

[ProgressIndicator2IP]

Global parameter defining the progress indicator (PI) sent to the IP.

You can also configure the feature per specific calls, using IP Profiles ('Progress Indicator to IP' parameter) or Tel Profiles ('Progress Indicator to IP' parameter). For a detailed description of the parameter and for configuring the feature, see Configuring IP Profiles or Configuring Tel Profiles.

Note: If you configure this feature for a specific profile, the device ignores this global parameter for calls associated with the profile.

[EnableRekeyAfter181]

Enables the device to send a re-INVITE with a new (different) SRTP key (in the SDP) if a SIP 181 response is received ("call is being forwarded"). The re-INVITE is sent immediately upon receipt of the 200 OK (when the call is answered).

[0] = Disable (default)
[1] = Enable

Note: The parameter is applicable only if SRTP is used.

configure voip > sip-definition settings > number-of-active-dialogs

[NumberOfActiveDialogs]

Defines the maximum number of concurrent, outgoing SIP REGISTER dialogs. The parameter is used to control the registration rate.

The valid range is 1 to 20. The default is 20.

Note:

Once a 200 OK is received in response to a REGISTER message, the REGISTER message is not considered in this maximum count limit.
The parameter applies only to outgoing REGISTER messages (i.e., incoming is unlimited).

'Network Node ID'

configure voip > sip-definition settings > net-node-id

[NetworkNodeId]

Defines the Network Node Identifier of the device for Avaya UCID.

The valid value range is1 to 0x7FFF. The default is 0.

Note:

To use this feature, you must set the parameter to any value other than 0.
To enable the generation by the device of the Avaya UCID value and adding it to the outgoing INVITE sent to the IP Group (Avaya entity), use the IP Groups table's parameter 'UUI Format'.

'Default Release Cause'

configure voip > sip-definition settings > dflt-release-cse

[DefaultReleaseCause]

Defines the default Release Cause (sent to IP) for IP-to-Tel calls when the device initiates a call release and an explicit matching cause for this release is not found.

The default release cause is NO_ROUTE_TO_DESTINATION (3). Other common values include NO_CIRCUIT_AVAILABLE (34), DESTINATION_OUT_OF_ORDER (27), etc.

Note:

The default release cause is described in the Q.931 notation and is translated to corresponding SIP 40x or 50x values (e.g., 3 to SIP 404, and 34 to SIP 503).
When the Trunk is disconnected or is not synchronized, the internal cause is 27. This cause is mapped, by default, to SIP 502.
For mapping SIP-to-Q.931 and Q.931-to-SIP release causes, see Configuring Release Cause Mapping.
For a list of SIP responses-Q.931 release cause mapping, see Alternative Routing to Trunk upon Q.931 Call Release Cause Code.

'Enable Microsoft Extension'

configure voip > sip-definition settings > microsoft-ext

[EnableMicrosoftExt]

Enables the modification of the called and calling number for numbers received with Microsoft's proprietary "ext=xxx" parameter in the SIP INVITE URI user part. Microsoft Office Communications Server sometimes uses this proprietary parameter to indicate the extension number of the called or calling party.

[0] Disable (default)
[1] Enable

For example, if a calling party makes a call to telephone number 622125519100 Ext. 104, the device receives the SIP INVITE (from Microsoft's application) with the URI user part as INVITE sip:622125519100;ext=104@10.1.1.10 (or INVITE tel:622125519100;ext=104). If the parameter [EnableMicrosofExt] is enabled, the device modifies the called number by adding an "e" as the prefix, removing the "ext=" parameter, and adding the extension number as the suffix (e.g., e622125519100104). Once modified, the device can then manipulate the number further, using the Number Manipulation tables to leave only the last 3 digits (for example) for sending to a PBX.

configure voip > sip-definition settings > sip-uri-for-diversion-header

[UseSIPURIForDiversionHeader]

Defines the URI format in the SIP Diversion header.

[0] = 'tel:' (default)
[1] = 'sip:'

configure voip > sip-definition settings > 100-to-18x-timeout

[TimeoutBetween100And18x]

Defines the timeout (in msec) between receiving a 100 Trying response and a subsequent 18x response. If a 18x response is not received within this timeout period, the call is disconnected.

The valid range is 0 to 180,000 (i.e., 3 minutes). The default is 32000 (i.e., 32 sec).

configure voip > sip-definition settings > immediate-trying

[EnableImmediateTrying]

Determines if and when the device sends a 100 Trying in response to an incoming INVITE request.

[0] = 100 Trying response is sent upon receipt of a Proceeding message from the PSTN.
[1] = (Default) 100 Trying response is sent immediately upon receipt of INVITE request.

configure voip > sip-definition settings > trans-coder-present

[TransparentCoderPresentation]

Determines the format of the Transparent coder representation in the SDP.

[0] = clearmode (default)
[1] = X-CCD

configure voip > sip-definition settings > ignore-remote-sdp-mki

[IgnoreRemoteSDPMKI]

Determines whether the device ignores the Master Key Identifier (MKI) if present in the SDP received from the remote side.

[0] = (Default) Disable
[1] = Enable

'Comfort Noise Generation Negotiation'

configure voip > media rtp-rtcp > com-noise-gen-nego

[ComfortNoiseNegotiation]

Enables negotiation and usage of Comfort Noise (CN) for Gateway calls.

[0] Disable
[1] Enable (default)

The use of CN is indicated by including a payload type for CN on the media description line of the SDP. The device can use CN with a codec whose RTP time stamp clock rate is 8,000 Hz (G.711/G.726). The static payload type 13 is used. The use of CN is negotiated between sides. Therefore, if the remote side doesn't support CN, it is not used. Regardless of the device's settings, it always attempts to adapt to the remote SIP UA's request for CNG, as described below.

To determine CNG support, the device uses the [ComfortNoiseNegotiation] parameter and the codec’s SCE (silence suppression setting) using the [CodersGroup] parameter.

If the [ComfortNoiseNegotiation] parameter is enabled, then the following occurs:

If the device is the initiator, it sends a “CN” in the SDP only if the SCE of the codec is enabled. If the remote UA responds with a “CN” in the SDP, then CNG occurs; otherwise, CNG doesn't occur.
If the device is the receiver and the remote SIP UA doesn't send a “CN” in the SDP, then no CNG occurs. If the remote side sends a “CN”, the device attempts to be compatible with the remote side and even if the codec’s SCE is disabled, CNG occurs.

If the [ComfortNoiseNegotiation] parameter is disabled, then the device doesn't send “CN” in the SDP. However, if the codec’s SCE is enabled, then CNG occurs.

Note: The parameter is applicable only to the Gateway application.

configure voip > sip-definition settings > sdp-ecan-frmt

[SDPEcanFormat]

Defines the echo canceller format in the outgoing SDP. The 'ecan' attribute is used in the SDP to indicate the use of echo cancellation.

[0] = (Default) The 'ecan' attribute appears on the 'a=gpmd' line.
[1] = The 'ecan' attribute appears as a separate attribute.
[2] = The 'ecan' attribute is not included in the SDP.
[3] = The 'ecan' attribute and the 'vbd' parameter are not included in the SDP.

Note: The parameter is applicable only when the [IsFaxUsed] parameter is set to 2, and for re-INVITE messages generated by the device as result of modem or fax tone detection.

'First Call Ringback Tone ID'

configure voip > sip-definition settings > 1st-call-rbt-id

[FirstCallRBTId]

Defines the index of the first ringback tone in the CPT file. This option enables an Application server to request the device to play a distinctive ringback tone to the calling party according to the destination of the call. The tone is played according to the Alert-Info header received in the 180 Ringing SIP response (the value of the Alert-Info header is added to the value of the parameter).

The valid range is -1 to 1,000. The default is -1 (i.e., play standard ringback tone).

Note:

It is assumed that all ringback tones are defined in sequence in the CPT file.
In case of an MLPP call, the device uses the value of the parameter plus 1 as the index of the ringback tone in the CPT file (e.g., if this value is set to 1, then the index is 2, i.e., 1 + 1).

'Presence Publish IP Group ID'

[PresencePublishIPGroupId]

Assigns the IP Group (by ID) configured for the Skype for Business Server (presence server). This is where the device sends SIP PUBLISH messages to notify of changes in presence status of Skype for Business users when making and receiving calls using third-party endpoint devices.

For more information on integration with Microsoft presence, see Microsoft Skype for Business Presence of Third-Party Endpoints.

'Microsoft Presence Status'

[EnableMSPresence]

Enables the device to notify (using SIP PUBLISH messages) Skype for Business Server (presence server) of changes in presence status of Skype for Business users when making and receiving calls using third-party endpoint devices.

[0] Disable (default)
[1] Enable

For more information on integration with Microsoft presence, see Microsoft Skype for Business Presence of Third-Party Endpoints.

'PSTN Alert Timeout'

configure voip > sip-definition settings > pstn-alert-timeout

[PSTNAlertTimeout]

Defines the Alert Timeout (in seconds) for calls sent to the PSTN. This timer is used between the time a Setup message is sent to the Tel side (IP-to-Tel call establishment) and a Connect message is received. If an Alerting message is received, the timer is restarted. If the timer expires before the call is answered, the device disconnects the call and sends a SIP 408 request timeout response to the SIP party that initiated the call.

The valid value range is 1 to 600 (in seconds). The default is 180.

Note:If per trunk configuration, using the [TrunkPSTNAlertTimeout] parameter, is set to other than default, the [PSTNAlertTimeout] parameter value is overridden.

'RTP Only Mode'

configure voip > sip-definition settings > rtp-only-mode

[RTPOnlyMode]

Enables the device to send and receive RTP packets to and from remote endpoints without the need to establish a SIP session. The remote IP address is determined according to the Tel-to-IP Routing table (Prefix parameter). The port is the same port as the local RTP port (configured by the [BaseUDPPort] parameter and the channel on which the call is received).

[0] Disable (default)
[1] Transmit & Receive = Send and receive RTP packets.
[2] Transmit Only= Send RTP packets only.
[3] Receive Only= Receive RTP packets only.

Note:

The parameter is applicable only to the Gateway application.
Digital interfaces: To activate the RTP Only feature without using ISDN signaling, you must do the following:
Configure E1/T1 Transparent protocol type (set the [ProtocoType] parameter to 5 or 6).
Enable the TDM-over-IP feature (set the [EnableTDMoverIP] parameter to 1).
To configure the RTP Only mode per trunk, use the [RTPOnlyModeForTrunk_x] parameter.
If per trunk configuration (using the [RTPOnlyModeForTrunk_ID] parameter) is set to a value other than the default, the [RTPOnlyMode] parameter value is ignored.

[RTPOnlyModeForTrunk_x]

Enables the RTP Only feature per trunk. The x in the parameter name denotes the trunk number, where 0 is Trunk 1. For a description of the parameter, see the [RTPOnlyMode] parameter.

Note: For using the global parameter (i.e., setting the RTP Only feature for all trunks), set the parameter to -1 (default).

'Media IP Version Preference'

configure voip > media settings > media-ip-ver-pref

[MediaIPVersionPreference]

Global parameter that defines the preferred RTP media IP addressing version (IPv4 or IPv6) for outgoing SIP calls. You can also configure this feature per specific calls, using IP Profiles ('Media IP Version Preference' parameter). For a detailed description of the parameter and for configuring this feature in the IP Profiles table, see Configuring IP Profiles.

'SIT Q850 Cause'

configure voip > sip-definition settings > sit-q850-cause

[SITQ850Cause]

Defines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when a Special Information Tone (SIT) is detected on an IP-to-Tel call.

The valid range is 0 to 127. The default is 34.

Note: For mapping specific SIT tones, use the following parameters: [SITQ850CauseForNC], [SITQ850CauseForIC], [SITQ850CauseForVC], and [SITQ850CauseForRO].

'SIT Q850 Cause For NC'

configure voip > sip-definition settings > release-cause-for-sit-nc

[SITQ850CauseForNC]

Defines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-NC (No Circuit Found Special Information Tone) is detected from the Tel side for IP-to-Tel calls.

The valid range is 0 to 127. The default is 34.

Note: When not configured (i.e., default), the [SITQ850Cause] parameter is used.

'SIT Q850 Cause For IC'

configure voip > sip-definition settings > q850-cause-for-sit-ic

[SITQ850CauseForIC]

Defines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-IC (Operator Intercept Special Information Tone) is detected from the Tel for IP-to-Tel calls.

The valid range is 0 to 127. The default is -1 (not configured).

Note: When not configured (i.e., default), the [SITQ850Cause] parameter is used.

'SIT Q850 Cause For VC'

configure voip > sip-definition settings > q850-cause-for-sit-vc

[SITQ850CauseForVC]

Defines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-VC (Vacant Circuit - non-registered number Special Information Tone) is detected from the Tel for IP-to-Tel calls.

The valid range is 0 to 127. The default is -1 (not configured).

Note: When not configured (i.e., default), the {SITQ850Cause] parameter is used.

'SIT Q850 Cause For RO'

configure voip > sip-definition settings > q850-cause-for-sit-ro

[SITQ850CauseForRO]

Defines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-RO (Reorder - System Busy Special Information Tone) is detected from the Tel for IP-to-Tel calls.

The valid range is 0 to 127. The default is -1 (not configured).

Note: When not configured (i.e., default), the [SITQ850Cause] parameter is used.

configure voip > message settings > inbound-map-set

[GWInboundManipulationSet]

Gateway application only: Assigns a Manipulation Set ID for manipulating all inbound INVITE messages.

Gateway and SBC applications: Assigns a Manipulation Set ID for manipulating incoming responses of requests that the device initiates.

The Manipulation Set is defined using the [MessageManipulations] parameter. By default, no manipulation is done (i.e. Manipulation Set ID is set to -1).

For more information, see Configuring SIP Message Manipulation.

configure voip > message settings > outbound-map-set

[GWOutboundManipulationSet]

Gateway application only: Assigns a Manipulation Set ID for manipulating all outbound INVITE messages.

Gateway and SBC applications: Assigns a Manipulation Set ID for manipulating outgoing requests that the device initiates.

The Manipulation Set is defined using the [MessageManipulations] parameter. By default, no manipulation is done (i.e. Manipulation Set ID is set to -1).

For more information, see Configuring SIP Message Manipulation.

'WebSocket Keep-Alive Period'

configure voip > sip-definition settings > websocket-keepalive

[WebSocketProtocolKeepAlivePeriod]

Defines how often (in seconds) the device sends ping messages (keep alive) to check whether the WebSocket session with the Web client is still connected.

The valid value is 5 to 2000000. The default is 0 (i.e., ping messages are not sent).

For more information on WebSocket, see SIP over WebSocket.

Note:

The device always replies to WebSocket ping control messages with pong messages.

'Registered User MOS Observation Window'

configure voip > qoe reg-user-voice-quality > mos-observ-win

[RegUserMosObservationWindow]

Defines the length of each interval (in hours) in the observation window (12 intervals) for calculating average MOS of calls belonging to users registered with the device.

The valid value is 1 or 2. The default is 1.

As the device measures MOS in 12 intervals, if configured to 1, then MOS is measured over a 12 hour period; if configured to 2, then MOS is calculated over a 24 hour period. It measures the average and minimum MOS per interval. Intervals without calls are not used in the calculation.

For more information on this feature, see Configuring Voice Quality for Registered Users.

Note: This parameter is applicable only to the SBC application.

'MOS Stored Timeout For No Calls'

configure voip > qoe reg-user-voice-quality > mos-stored-timeout-for-no-calls

[MosStoredTimeoutForNoCalls]

Defines the duration (in minutes) of no calls after which the MOS measurement is reset (0 and gray color). In addition, if an alternative IP Profile is configured for the Quality of Service rule and is currently being used, the device changes back to the original IP Profile.

The valid value range is 1 to 1,440. The default is 60.

For more information on this feature, see Configuring Voice Quality for Registered Users.

Note: This parameter is applicable only to the SBC application.

configure voip > sip-definition settings > message-policy-reject-response-type

[MessagePolicyRejectResponseType]

Defines the SIP response code that the device sends when it rejects an incoming SIP message due to a matched Message Policy in the Message Policies table, whose 'Send Reject' parameter is configured to Policy Reject.

The default is 400 "Bad Request".

To configure Message Policies, see Configuring SIP Message Policy Rules.

[ENUMAllowNonDigits]

Defines if non-digits can be included in ENUM queries sent by the device to an ENUM server for retrieving a SIP URI address for an E.164 telephone number (destination).

[0] = (Default) Disable – non-digits are not accepted in ENUM queries. For example: 9.2.0.0.3.0.9.3.0.3.0.2.5.3.4.4.2.5.7.7.7.8.My_Domain
[1] = Enable – non-digits are accepted in ENUM queries (request). For example: 0.0.0.0.0.2.3.3.3.3.2.2.*.9.9.j.a.k.s.*.j.k.a.n.d.b.j.s.+.My_Domain

For the Gateway application: ENUM queries can be used for Tel-to-IP Routing (see Configuring Tel-to-IP Routing Rules). For the SBC application: ENUM queries can be used for IP-to-IP routing with Call Setup Rules (see Configuring SBC IP-to-IP Routing Rules and Configuring Call Setup Rules).

'Regions Connectivity Dial Plan'

configure voip > sbc settings > regions-connectivity-dial-plan

[RegionsConnectivityDialPlan]

Defines the Dial Plan that the device must search in the Dial Plans table to check if the source and destination Teams sites share a common group number. If they do, the call is a direct media call.

For more information, see Using Dial Plans for Microsoft Local Media Optimization

Note: The ini file parameter is a table, using the following syntax:

[ RegionsConnectivityDialPlan ]

FORMAT Index = RCDialPlan;

RegionsConnectivityDialPlan 0 = "NameofDialPlan";

[ \RegionsConnectivityDialPlan ]

Note: The feature is applicable only to Teams-to-PSTN calls.

configure voip > sip-definition settings > preserve-multipart-content-type

[PreserveMultipartContentType]

Defines the device's handling of the SIP Content-Type header's value when the device sends a SIP message that has multiple bodies.

[0] = (Default) Disabled. The device sets the type parameter in the Content-Type header to "multipart/mixed" and adds a unique value to the 'boundary' parameter of the Content-Type header.
[1] = Enabled. The device doesn’t change the type or boundary parameter of the Content-Type header. For example, if the incoming message contains 'Content-Type: multipart/relative;boundary=<someUniqueValue>', then this is how the Content-Type will be in the outgoing message.

Note: The parameter is applicable only to the SBC application.

Out-of-Service (Busy Out) Parameters

'Enable Busy Out'

configure voip > sip-definition settings > busy-out

[EnableBusyOut]

Enables the Busy Out feature.

[0] Disable (Default)
[1] Enable

When enabled and certain scenarios exist, the device does the following:

Digital: All trunks are automatically taken out-of-service by taking down the D-Channel.

The above behavior is done upon one of the following scenarios:

The device is physically disconnected from the network (i.e., Ethernet cable is disconnected).
The device can't communicate with the Proxy Sets (according to the Proxy Keep-Alive mechanism) associated with the destination IP Groups of matching routing rules in the Tel-to-IP Routing table and no other alternative route exists to send the call.
The IP Connectivity mechanism is enabled (by the [AltRoutingTel2IPEnable] parameter) and there is no connectivity to any destination IP address of matching routing rules in the Tel-to-IP Routing table.

Note:

If you enable the [AltRoutingTel2IPEnable] parameter, the Busy Out feature doesn't function with the Proxy Set keep-alive mechanism. To use the Busy Out feature with the Proxy Set keep-alive mechanism (for IP Groups), disable the [AltRoutingTel2IPEnable] parameter.
The Busy Out behavior depends on the PSTN protocol type.
The Busy Out condition is also applied per Trunk Group. This occurs if there is no connectivity to the Serving IP Group of a specific Trunk Group configured in the Trunk Group Settings table. In such a scenario, all the physical trunks of the Trunk Group are set to the Busy Out condition. Each trunk uses the out-of-service method according to the ISDN variant.
To configure the method for taking trunks/channels out-of-service, see the [DigitalOOSBehaviorForTrunk_x] parameter for per trunk or the [DigitalOOSBehavior] parameter for all trunks.

'Graceful Busy Out Timeout'

configure voip > sip-definition settings > graceful-bsy-out-t-out

[GracefulBusyOutTimeout]

Defines the timeout interval (in seconds) for out-of-service graceful shutdown mode for busy trunks (per trunk) if communication fails with a Proxy server (or Proxy Set). In such a scenario, the device rejects new calls from the PSTN (i.e., Serving Trunk Group), but maintains currently active calls for this user-defined timeout. Once this timeout elapses and there are still active calls, the device terminates the calls and takes the trunk out-of-service (sending the PSTN busy-out signal). Trunks without any active calls are immediately taken out-of-service regardless of the timeout.

The parameter is applicable to the locking of Trunk Groups feature (see Locking and Unlocking Trunk Groups) and the Busy Out feature (see the [EnableBusyOut] parameter), where trunks/channels are taken out-of-service.

The range is 0 to 86,400. The default is 0.

Note:

The parameter is applicable only to digital interfaces.
To configure the method for taking trunks/channels out-of-service, see the [DigitalOOSBehaviorForTrunk_x] parameter for per trunk or the [DigitalOOSBehavior] parameter for all trunks.

configure voip > gateway digital settings > isdn-busy-out-based-on-table

[ISDNBusyOutBasedOnTable]

Defines which configuration table (Trunk Group Settings table or Tel-to-IP Routing table) the device uses to determine busy out for a Trunk Group.

[0] = (Default) Busy Out is determined by the Trunk Group Settings table (see Configuring Trunk Group Settings). Busy Out of a Trunk Group occurs if its associated Serving IP Group in the table is down.
[1] = Busy Out is determined by the Tel-to-IP Routing table (see Configuring Tel-to-IP Routing Rules). Busy Out of a Trunk Group occurs only when all its associated destination IP Groups in the table are down. Busy Out is cleared when at least one IP Group is up.

Note:

The parameter is applicable only to digital (ISDN) interfaces.
For this Busy Out feature, you need to enable proxy keep-alive for the Proxy Set associated with the IP Group.
For the parameter to take effect, a device restart is required.

Retransmission Parameters

'SIP T1 Retransmission Timer'

configure voip > sip-definition settings > t1-re-tx-time

[SipT1Rtx]

Defines the time interval (in msec) between the first transmission of a SIP message and the first retransmission of the same message.

The default is 500.

Note: The time interval between subsequent retransmissions of the same SIP message starts with SipT1Rtx. For INVITE requests, it is multiplied by two for each new retransmitted message. For all other SIP messages, it is multiplied by two until SipT2Rtx. For example, assuming SipT1Rtx = 500 and SipT2Rtx = 4000:

The first retransmission is sent after 500 msec.
The second retransmission is sent after 1000 (2*500) msec.
The third retransmission is sent after 2000 (2*1000) msec.
The fourth retransmission and subsequent retransmissions until [SIPMaxRtx] are sent after 4000 (2*2000) msec.

'SIP T2 Retransmission Timer'

configure voip > sip-definition settings > t2-re-tx-time

[SipT2Rtx]

Defines the maximum interval (in msec) between retransmissions of SIP messages (except for INVITE requests).

The default is 4000.

Note: The time interval between subsequent retransmissions of the same SIP message starts with SipT1Rtx and is multiplied by two until SipT2Rtx.

'SIP Maximum RTX'

configure voip > sip-definition settings > sip-max-rtx

[SIPMaxRtx]

Defines the maximum number of UDP transmissions of SIP messages (first transmission plus retransmissions).

The range is 1 to 30. The default is 7.

'Number of RTX Before Hot-Swap'

configure voip > sip-definition proxy-and-registration > nb-of-rtx-b4-hot-swap

[HotSwapRtx]

Defines the number of retransmitted INVITE/REGISTER messages before the call is routed (hot swap) to another Proxy/Registrar.

The valid range is 1 to 30. The default is 3.

For example, if configured to 3 and no response is received from an IP destination, the device attempts another three times to send the call to the IP destination. If still unsuccessful, it attempts to redirect the call to another IP destination.

Note: The parameter is also used for alternative routing (see Alternative Routing Based on IP Connectivity.

configure voip > sip-definition settings > usr2usr-hdr-frmt

[UserToUserHeaderFormat]

Defines the interworking between the SIP INVITE's User-to-User header and the ISDN User-to-User (UU) IE data.

[0] = (Default) SIP header format: X-UserToUser.
[1] = SIP header format: User-to-User with Protocol Discriminator (pd) attribute (according to IETF Internet-Draft draft-johnston-sipping-cc-uui-04). For example:

User-to-User=3030373435313734313635353b313233343b3834;pd=4

[2] = SIP header format: User-to-User with encoding=hex at the end and pd embedded as the first byte (according to IETF Internet-Draft draft-johnston-sipping-cc-uui-03). For example:

User-to-User=043030373435313734313635353b313233343b3834; encoding=hex

where "04" at the beginning of this message is the pd.

[3] = Interworks the SIP User-to-User header containing text format to ISDN UUIE in hexadecimal format, and vice versa. For example:

SIP Header in text format:

User-to-User=01800213027b712a;NULL;4582166;

Translated to hexadecimal in the ISDN UUIE:

303138303032313330323762373132613b4e554c4c3b343538323136363b

The Protocol Discriminator (pd) used in UUIE is "04" (IUA characters).